System, method and terminal for measuring the quality of service in a telecommunications network

ABSTRACT

The present invention relates to a system ( 10 ), method and terminal ( 14 ) for measuring the quality of service or QoS or services, for example, of the Internet type in which a telecommunications network ( 12 ) supports the delivery of the services by a server ( 16 ). The system ( 10 ) and the corresponding method allow to collect by means of the network ( 12, 18, 20 ) the QoS information, in particular information of insufficient QoS, to identify the causes of insufficient QoS and to discriminate in the attribution of said causes among the terminal ( 14 ), the server ( 16 ) or the network itself ( 12 ). The terminal ( 14 ) in addition to generating “objective” information about the QoS, such as the time for downloading a Web page, dimensions of the Web page and number of objects composing the page, is also able to generate “subjective” information, indicative of the actual QoS perceived by a user of the terminal ( 14 ).

TECHNICAL FIELD

The present invention relates to a system, method and terminal formeasuring the Quality of Service (QoS), for instance, for Internetservices, as indicated in the preamble to the independent claims.

In particular, the present invention relates to a system and a methodfor monitoring QoS in mobile telecommunications networks (mobilenetworks) which allow to make use of Internet services as well as to aterminal able to measure QoS information, for example, during WebBrowsing functions.

BACKGROUND ART

Systems and methods are known for monitoring QoS in transferringinformation (data) between a client terminal or user and an Internetserver.

For example, U.S. Pat. No. 6,021,439 discloses a system and method inwhich an Internet Service Provider (ISP) associates to predefined Webpages appropriate enabling keys able both to activate, at the clientterminal, predefined programs for collecting QoS parameters, and totransmit the collected parameters to the Service Provider.

A first problem shared by known systems and methods for collecting theQoS consists of the fact that such systems and methods provide for thecollection of specific QoS parameters of the Service Providers,neglecting parameters linked to the characteristics and functionality ofthe telecommunications network supporting the Internet services.

This approach, which is typical of known systems and methods, issubstantially unsatisfactory because it neglects one of the essentialelements of QoS for Internet services; QoS depends on the variousarchitectural elements that participate or contribute to the use ofInternet services, i.e. in part on devices or parameters under theService Provider's control, in part on devices or parameters linked tothe telecommunications network and to those responsible for itsoperation (operator), in part on devices or parameters associated to thetype of terminals or connections used by the clients themselves.

In other words, since all the architectural elements that participate orcontribute to the use of Internet services can cause an insufficientQoS, there is the problem of having available tools able to discriminatethe causes of insufficient QoS attributing the responsibilityindividually to said architectural elements.

An additional problem of the prior art, in particular in the case ofInternet services on mobile networks, consists of the fact that thetransmission of QoS parameters is limited to Service Providers only,whilst the clients of these types of services tend to ascribed theresponsibility for insufficient QoS, not to the Service Provider, but tothe network operator who, however, not having adequate tools available,due to the limited nature of known systems and methods, is incapable ofidentifying the causes of said insufficient QoS.

Therefore, the problem exists of making available to network operators,and not only to Service Providers, in particular in the case of mobilenetworks, adequate tools for collecting and managing QoS information.

Another problem of the prior art resides in the fact that the terminalsgenerally used to transmit the measurements are able to transmitabsolute QoS information, for instance, in terms of transfer times,number of Web pages transferred and so on, whilst for network operators,in particular in the case of mobile networks, but also for the ServiceProvider, it would be important to know subjective parameters, i.e.parameters indicative of clients' actual perception.

DISCLOSURE OF THE INVENTION

The aim of the present invention is to describe a system, correspondingmethod, terminal and computer product that allow in particular networkoperators to collect QoS parameters, to discriminate the causes and thecorresponding architectural elements causing insufficient QoS, and todetermine the actual QoS perceived by clients.

The aim is achieved by the system, method, terminal and computer productfor measuring Quality of Service (QoS) as claimed.

According to a first characteristic of the present invention, the systemand corresponding method allow to maintain updated clients' terminals insuch a way that the collection of the parameters of insufficient QoS andthe corresponding analysis are constantly kept homogeneous and/orconsistent.

According to another characteristics of the present invention, thesystem and corresponding method allow to identify, thanks to aparticular structure of a supporting data base, the causes ofinsufficient QoS and to discriminate in the attribution of said causesbetween the Internet Server, the telephone network and the client'sterminal, i.e. between the individual architectural elements thatcontribute to the use of the Internet services.

According to an additional characteristic of the present invention, eachclient's terminal is able to determine, in particular, subjectiveparameters indicative of the QoS as perceived by clients.

BRIEF DECRIPTION OF DRAWINGS

This and other characteristics of the present invention shall becomereadily apparent from the following description of a preferredembodiment, provided purely by way of non limiting example with the aidof the accompanying drawings, in which:

FIG. 1 shows a general block diagram of a system for measuring theQuality of Service;

FIG. 2, FIG. 3 and FIG. 4 show flow charts relating to the functions ofthe QoS server of the system of FIG. 1; and

FIG. 5 shows a general flow chart of the system of FIG. 1.

BEST MODE FOR CARRYING OUT THE INVENTION

With reference to FIG. 1, a system 10 for measuring the Quality ofService (QoS), for example, for Internet services, comprises userterminals (terminals) 14 associated with respective clients, Internetapparatuses or Servers (Internet Servers) 16 associated with InternetService Providers or ISP, a telecommunications network (network) 12associated with a network Operator.

The network 12 allows, in known fashion, the interconnection of theterminals 14 to the Internet Servers 16 and comprises, in accordancewith the present embodiment, network apparatuses (control units) 18 andan apparatus for managing the Quality of Service (QoS Server) 20,considered a possible characteristic element of the present invention.

The terminals 14, known from the hardware viewpoint, are constituted,for instance, by mobile terminals, by personal computers (PC) connectedto mobile terminals, by PCs or, in general, by terminals able to handleInternet functionalities such as searches on the network (Web Browsing),electronic mail (E-Mail) and data transfer (File Transfer).

The terminals 14 are able to connect, in known fashion, to an Internetserver 16, accessing the operator's network, for instance, by means ofpredefined telephone numbers, in the case of fixed networks or GSM(Global System for Mobile communication) networks or by means of PDPContext (Packet Data Protocol) procedures, in the case of GPRS (GeneralPacket Radio Service) networks.

The terminals 14 comprise, in accordance with the present embodiment,processing modules (terminal modules) constituted by program modules,for example written in a known programming language, such as C++, andare able, as shall be described in detail hereafter, to interact withInternet functionalities, to collect or generate, and possibly totransmit to the QoS Server 20, information or parameters representativeof the QoS perceived by the client, and to interact with the QoS server20 to keep updated the modules for collecting the QoS parameters.

In particular, according to a first possible characteristic of thepresent invention, the terminal modules are able to:

-   -   detect, in known fashion, the activation of Internet        functionalities, for instance of the Web Browsing type,        independently from the type of page and/or ISP in use;    -   request, if need be, the client's consent to measure and        transmit QoS parameters;    -   detect or generate QoS parameters, as shall be described in        detail hereafter; and    -   transmit to the QoS server 20, by means of appropriate processes        for connection to the QoS server 20, QoS information or        parameters collected or generated, in particular if said QoS        parameters are below predefined quality thresholds; this,        naturally, in order to limit traffic towards the QoS server 20        itself.

Naturally, although it is preferable that the terminal 14 transmit onlyparameters of insufficient QoS, nothing prohibits the terminal 14 fromtransmitting, in general, the QoS information generated during the useof functionalities, for example, of the Internet type.

The generation of the QoS parameters, according to further possiblecharacteristic elements of the present invention, comprises, forinstance, the following steps:

-   -   measuring the time “t” for downloading a complete page, for        instance in seconds;    -   measuring the dimensions “d” of the page, for instance in bytes;    -   measuring the number “c” of objects composing the page;    -   applying a correlation function F(t,d,c) able to estimate the        value Q of the QoS as perceived by the client by means of an        expression of the type Q=F(t,d,c); and    -   comparing the value of Q with Q_(RIF) values indicative of a        minimum acceptable level of quality.

According to a preferred embodiment, the correlation function Q=F(t,d,c)can, for instance, be determined a priori and experimentally, on astatistical basis, with the collaboration of a significant sample ofclients and be stored in the terminal 14 in the form of table with thevariation of discrete intervals of t (columns) and δ (rows) as shownbelow (Tab. 1). TAB. 1 t δ 0-5 5-10 10-20 20-30 >30  0-100 4 3 2 0 0100-200 4 4 2 1 0 200-300 4 4 2 2 0 >300 4 4 3 2 0The values of δ in Tab. 1 are determined by means of the followinglinear expression 1]:δ=(d/1000)+c  1]

The values on Tab. 1 are representative of the level of QoS perceived bythe clients in the various operative conditions and correspond to thevalues of Q as defined. In the example, the value of Q fall between 0and 4; to high values of Q, for example between 3 and 4, corresponds ahigh quality of service as perceived by the client, whereas to lowvalues, for instance between 0 and 2, corresponds an insufficient QoS asperceived by the client.

Through the use of a correlation function of the kind described above,it is thereby possible to associate to objective parameters of the QoSthe subjective parameter Q, thus indicative of the QoS as perceived bythe clients.

The transmission of the parameters of QoS can be performed by settingup, in known fashion by means of the terminal modules, in parallel tothe connection to the Internet server 16, a concurrent connection to theQoS server 20 in such a way as to transmit, for instance in encryptedand secure fashion, the parameters of insufficient QoS to the QoS server20.

The terminal modules, according to a further possible characteristicelement of the present invention, are able to be updated and/or replacedwith new modules, for example by the QoS server 20.

In fact, it is possible for the QoS server 20, as shall be described indetail hereafter, to dynamically update the correlation functionF(t,d,c) and the Q_(RIF) levels with variations, for instance, ofparameters known to the network 12 such as:

-   -   type of connection between terminal 14 and network 12, for        example connection of the circuit type, GPRS 2+1, GPRS 3+1,        etc.;    -   performance level subscribed by the client; and other similar        characteristics.

Naturally, the above description is applicable in similar fashion toInternet functionalities other than Web Browsing.

Thanks to said additional characteristic, it is thus possible for thetelephone operator to modify dynamically, as service conditions vary,the terminal modules in such a way as to identify the causes ofinsufficient QoS as perceived by the client.

The control units 18, of known type, are part, for instance, of aGSM/GPRS network 12 and comprise units of GGSN (Gateway GPRS SupportNode) type, SGSN (Serving GPRS Support Node) type and HLR (Home LocationRegister) type; such units are able to allow the exchange of data andcommands between the terminals 14, the Internet server 16 and the QoSserver 20 by means of the connections established by the terminal 14.

The SGSN and HLR units, as is well known, further comprise referencedatabases containing parameters that, according to present embodiment,can be collected by the QoS server 20, as shall be described in detailhereafter.

In general, the control units 18 are able, according to present exampleof embodiment, to allow both the retrieval of reference information andthe transmission to the QoS server 20 of some parameters, collected bythe terminals 14, useful to the implementation of the system and methodaccording to the invention, such as:

-   -   indicator of consent to the handling of QoS parameters (status        indicator);    -   identifier of the calling terminal 14;    -   URL identifier requested by the client;    -   notification of the start and end of the connection.

The QoS server 20 is constituted, for example, by an electronic computer(computer) 25, known in itself, for instance a Pentium® III computerwith dual CPU, 512 Mbytes internal Ram and Windows® NT operating systemand a known subsystem of disks (disk) 22, connected to the processor 25and able to store, for example in a first zone 22 a, reference databasesand, in a second zone 22 b, processing or program modules (servermodules) developed during the design of the system 10 to identify, inparticular, the causes of insufficient QoS as measured by the terminals14.

According to the present embodiment, the reference databases stored inthe first zone 22 a of the disk 22 comprise:

-   -   a QoS database able to contain, stored therein, the QoS or        insufficient QoS data as transmitted by the client terminals 14;    -   a service database (active client database) able to contain,        stored therein, instant by instant, indicative information of        the active clients on services of the Internet type;    -   an address database able to contain, stored therein, the URL        (Uniform Resource Locator) address identifying, as is well        known, Internet systems or Internet resources.

The server modules, stored in the zone 22 b of the disk 22, comprise:

-   -   interface modules able to interface the control unit 18;    -   at least a data collection module able to        -   selectively detect the activation of an Internet connection            by the terminal 14 of a determined client;        -   store any QoS data transmitted by the client terminal 14 in            the QoS data base in order to process said data in            subsequent steps;        -   keep updated the active client data base;    -   at least a data management module able to        -   read the information stored in the QoS data base;        -   read the information present in the active client data base;        -   transmit to the terminals 14, in selective fashion, the            terminal modules or update them if necessary;        -   transmit to the terminals 14, in selective fashion, new            correlation functions or update them if necessary;        -   transmit to the terminals 14, in selective fashion, new            Q_(RIF) values representative of the levels of minimum            acceptable quality if necessary;        -   modify the status of a terminal 14 in selective fashion, for            example deactivating its monitoring of perceived QoS;        -   update the address data base if necessary;        -   process the data of insufficient QoS stored in the QoS data            base in order to initiate, as shall be described in detail            hereafter, actions to correct the detected and stored            deficiencies.

In order to better clarify the characteristics of the present invention,an example of structure of the QoS data base is provided hereafter alongwith some examples of the processing operations that can be conductedautomatically through the analysis of the data stored in the QoS database.

In a preferred embodiment, the QoS data base comprises, stored forinstance in the form of a table, strings of elementary information orrecords able to be indexed individually relating to conditions ofinsufficient QoS; each record comprises the following elementaryinformation or fields:

-   -   a field indicative of the client from whom the parameters of        insufficient QoS have arrived;    -   a field or time reference indicative of the instant in which the        parameters of insufficient perceived QoS were transmitted to the        QoS server 20;    -   a field or reference K indicative of the type of terminal and/or        of the type of connection used by the client;    -   a field or reference F indicative of the correlation function in        use by the client;    -   a field or value Q corresponding to the level of insufficient        QoS measured by the client terminal 14 and transmitted to the        QoS server 20;    -   a field or value Q_(RIF) indicative of the level of acceptable        minimum acceptable quality in use by the client;    -   fields comprising the absolute values of “t”, “d” and “c” as        measured by the client terminal 14 and corresponding to the        level of insufficient QoS;    -   a field or value of URL indicative of the address of the        Internet service corresponding to the situation of insufficient        level of QoS;    -   a field or reference P indicative of the position of the        terminal 14 in the territory.

As is readily apparent to a person versed in the art, each recordcomprises both elementary information transmitted by the terminals 14and other information collected, for example, by the operator throughthe control units 18 or other apparatuses belonging to the network 12.

For example, the elementary information about the position of theterminal 14 can be collected by the QoS server 20, in known fashion, byquerying, in the case of GSM/GPRS networks, the data bases of the SGSNand HLR units.

Having available the data base QoS constructed, for instance, in theindicated manner, it is possible, as shall be described in detailhereafter, to conduct automatic processing operations able both toidentify in selective fashion the problems and the causes ofinsufficient QoS and, if need be, to solve them.

A first example of analysis (200) is able to allow to identify, with adetermined time interval and analysing the data base QoS, the causes ofinsufficient QoS due to the characteristics of the Web pages used by theclients or to the ISP.

Said analysis (200) comprises the steps of:

-   -   selecting a determined URL address (FIG. 2, step 210), for        example a URL of frequent use and/or indicated by some clients        as not meeting QoS requirements;    -   determining the number of records N (step 220) present in the        QoS data base corresponding to the selected URL having identical        or equivalent F and Q_(RIF);    -   comparing the number N thus determined with a maximum number        New, predetermined or determined on each occasion (step 230);    -   if N is smaller than or equal to N_(MAX) (negative outcome of        the comparison), repeating the procedure by selecting an        additional URL (step 210) or completing the analysis function if        there are no other URLs to select (step STOP);    -   if N is greater than N_(MAX) (positive outcome of the        comparison), mutually comparing the references P (step 240)        indicative of the area in relation to the N records determined        in the step 220;    -   if P is identical or equivalent (COSTANT) for all N records        (positive outcome), starting a network analysis procedure aimed        at verifying any connection problems in the identified area P        (step 245);    -   if the reference P is diversified (NOT COSTANT) for the N        records (negative outcome), mutually comparing the references K        (step 250) indicative of the characteristics of the terminals        and/or of the type of connection;    -   if the reference K is identical or equivalent (COSTANT) for all        N records (positive outcome), starting an analysis procedure        aimed at verifying any problems due to the type of terminal 14        (FIG. 1, FIG. 2) and or of connection identified (step 255);    -   if the reference K is diversified (NOT COSTANT) for the N        records (negative outcome), assigning to the URL address being        analysed an unreliability or reduced QoS parameter and        transmitting a signalling to the corresponding ISP and, as the        case may be, to the client (step 270).

A second example of analysis (300) is able to allow to identify, with adetermined time interval and analysing the QoS database, the causes ofinsufficient QoS due to the telephone operator.

This type of analysis (300) is particularly useful in the case of mobileterminals able to use, for instance, Internet services by means ofGSM/GPRS technology (Global System for Mobile communication/GeneralPacket Radio Service) or UMTS technology (Universal MobileTelecommunication System).

This second example of analysis (300) comprises the steps of:

-   -   selecting a determined elementary area of territory P (step 310,        FIG. 3), for example an area P with intense traffic and/or        signalled by some clients as not meeting QoS requirements;    -   determining the number of records N (step 320) present in the        QoS database corresponding to the selected reference P having        identical or equivalent F and Q_(RIF);    -   comparing the number N thus determined to maximum number N_(MAX)        predetermined or determined on each occasion (step 330);    -   if N is smaller than or equal to N_(MAX) (negative outcome of        the comparison), repeating the procedure selecting an additional        reference P (step 310) or completing the analysis function if        there are no other areas to select (step STOP);    -   if N is greater than N_(MAX) (positive outcome of the        comparison), mutually comparing the URL values (step 340)        indicative of the addresses used by the clients in relation to        the N records determined in the step 320;    -   if the URL values are identical or equivalent (COSTANT) for all        N records (positive outcome), starting an analysis procedure        aimed at verifying any problems associated with the identified        ISP (step 345);    -   if the URL values are diversified (NOT COSTANT) for the N        records (negative outcome), mutually comparing the references K        (step 350) indicative of the characteristics of the terminals        and/or of the type of connection;    -   if the reference K is identical or equivalent (COSTANT) for all        N records (positive outcome), starting an analysis procedure        aimed at verifying any problems due to the type of terminal 14        (FIG. 1, FIG. 3) and/or of connection identifying (step 355);    -   if the reference K is diversified (NOT COSTANT) for the N        records (negative outcome), assigning to the reference area P        being analysed an unreliability or reduced QoS parameter and        transmitting a specific notification to any personnel performing        technical assistance and/or support functions within the        telephone operator organisation (step 370).

A third example of analysis (400) is able to allow to identify, with adetermined time interval and by analysing the QoS database, the causesof insufficient QoS due to the characteristics of the terminal and/or ofthe types of connection used by the clients.

This type of analysis (400) is particularly effective, for example, inthe case of mobile terminals having diversified quality characteristicsand/or in the case of Internet services supported by atelecommunications network having different characteristics according tothe type of data transport technology and/or client contract.

This third example of analysis (400) comprises the steps of:

-   -   selecting a determined type of terminal or connection K (step        410, FIG. 4), for example a reference “K” of a terminal type of        low quality and/or signalled by some clients as not meeting QoS        requirements;    -   determining the number of records N (step 420) present in the        QoS data base corresponding to the selected reference K having        identical or equivalent F and Q_(RIF);    -   comparing the number N thus determined to a maximum number        N_(MAX), predetermined or determined on each occasion (step        430);    -   if N is smaller than or equal to N_(MAX) (negative outcome of        the comparison), repeating the procedure selecting an additional        reference K (step 410) or completing the analysis function if        there are no other types of terminal or connection to select        (step STOP);    -   if N is greater than N_(MAX) (positive outcome of the        comparison), mutually comparing the references P (step 440)        indicative of the area in relation to the N records determined        in the step 420;    -   if P is identical or equivalent (COSTANT) for all N records        (positive outcome), starting a network analysis procedure aimed        at verifying any connection problems in the identified area P        (step 445);    -   if the reference P is diversified (NOT COSTANT) for the N        records (negative outcome), mutually comparing the values of URL        (step 440) indicative of the addresses used by the clients in        relation to the N records determined in the step 420;    -   if the values of URL are identical or equivalent (COSTANT) for        all N records (positive outcome), starting an analysis procedure        aimed at verifying any problems associated to the identified ISP        (step 455);    -   if the values of URL are diversified for the N records (negative        outcome), assigning to the type of terminal and/or to the type        of connection with reference K an unreliability or insufficient        QoS parameter and transmitting to the clients messages        indicating the causes and/or any solutions to the identified        problems (step 470).

Thanks to the automatic procedures described above, the QoS server 20(FIG. 1, FIG. 2, FIG. 3, FIG. 4) is able, based on the programsdeveloped during the design of the system 10 and of the QoS databasestored on the disk 22, to identify the causes of insufficient QoS and toattribute the detected causes to the corresponding architecturalelements co-operating to provide the Internet services.

The operation of the system 10 in regard to the collection andtransmission of the QoS parameters is as follows.

Given a connection of the client, by means of the terminal 14 (step 110;FIG. 1, FIG. 5) the terminal 14 itself transmits to the QoS server 20(step 120) parameters relating to the established Internet connection.

The QoS server 20 verifies, by means of the interface module or modules,whether the parameters allow to manage QoS information (step 130) and,if not, it suspends all monitoring function for the ongoing connection.

If they do, it activates the management module or modules residing onthe QoS server 20 (step 140). In particular, the QoS server 20 activatesa check of the characteristics of the QoS module residing on theterminal (terminal module) of the caller (step 145) to verify whethersaid module is updated or consistent with the active connection type.

If the outcome of the verification is negative (terminal module notupdated) the QoS server 20 by means of the management module activatesthe update of the terminal module (step 148), before activating the datacollection module or modules (step 170).

If the outcome is positive (terminal module updated) the data collectionmodule or modules is (are) directly activated (step 170) by updating theactive clients database.

The data collection module (step 170) of the QoS server 20 remainsactive throughout the duration of the connection in such a way that, ifduring the Internet functions carried out by the terminal 14 theinsufficient QoS threshold is exceeded and the terminal transmits thecollected data to the QoS server 20, then it can store the data thusreceived in the QoS database.

At the end of the connection, the terminal 14 signals its completion tothe QoS server 20 so that the QoS server 20 can accordingly update theactive clients database (step 180).

Naturally, as will be readily apparent to a person versed in the art,the completion of the connection can also be to determined byappropriate Time Outs to take into account any anomalous conditions ofthe connection.

Thanks to the architecture and to the operation described above,according to an additional characteristic element of the presentinvention, the server 20 is able, is by means of the modules developedduring the design of the system 10, to keep updated and, as the case maybe, “aligned” the parameters of the correlation function, thecorrelation function itself and/or the insufficient QoS thresholds, inorder to allow both the collection of insufficient QoS data and theanalysis of the mutually homogeneous collected data, comparable, forinstance, for the same type of connection or ISP.

The system, method and terminal have been described taking as areference the usage of Internet services, but, as will be readilyapparent to a person versed in the art, the invention as a whole is alsoapplicable to the usage of generic services by means of atelecommunications network in which the services are constituted byinformation or data to be retrieved and in which the QoS as perceived bythe client depends on the different architectural elements of thesystem.

The system, method and terminal have been described taking as referenceobjective QoS parameters such as time for downloading a complete page,dimensions of the page, number of objects composing the page, and aparticular correlation function F, but, as will be readily apparent to aperson versed in the art, the invention maintains its validity also inthe case of use of objective values and correlation functions of anothertype.

Obvious modifications or variations are possible to the abovedescription, in dimensions, shapes, materials, components, circuitelements, connections and contacts, as well as in the details of thecircuitry and of the construction illustrated herein and of the methodof operation without departing from the spirit of the invention as setout in the claims that follow.

1. System (10) for measuring the quality of service (QoS) relating toservices rendered by means of a telecommunications network (12, 18)comprising: at least one terminal (14) comprising access modules able toaccess the services and to generate and transmit QoS information; atleast a service apparatus (16) able to provide said services to a userof the terminal (14) through the telecommunications network (12, 18);characterised in that said telecommunications network (12, 18)comprises: QoS collecting information device (20), able to collect theQoS information transmitted by said terminal (14) during the delivery ofsaid services by said service apparatus (16).
 2. System as claimed inclaim 1, characterised in that said telecommunications network (12, 18)also comprises analysing modules (20) able to analyse the collected QoSinformation in order to identify causes of insufficient QoS; and toattribute (200, 300, 400) the causes of insufficient QoS to saidterminal (14), to said network (12, 18) or to said apparatus (16). 3.System as claimed in claim 1 characterised in that said modules of saidterminal (14) able to generate QoS information comprise: measuringmodules able to measure objective QoS parameters (t, d, c); andparameter correlation modules able to correlate said objectiveparameters (t, d, c) with subjective parameters (Q) representative ofthe QoS as perceived by the user of said terminal (14).
 4. System asclaimed in claim 1 characterised in that said telecommunications network(12, 18) comprises terminal updating modules able to update at leastsaid modules able to generate QoS information of said terminal (14). 5.Method for measuring the quality of service relating to servicesdistributed through a telecommunications network (12) comprising thestep of: accessing (110) by a user by means of a terminal (14) able togenerate QoS information to a service apparatus (16) able to providesaid services; characterised by the steps of collecting (170), by meansof said telecommunications network (12) the QoS information generated bysaid terminal (14).
 6. Method as claimed in claim 5 characterised by theadditional steps of analysing (170), by said telecommunications network(12), said QoS information in order to identify causes of insufficientQoS; attributing (200, 300, 400) the causes of insufficient QoS to saidterminal (14), to said network (12, 18) or to said service apparatus(16).
 7. Method as claimed in claim 5 characterised in that thegeneration of QoS information by said terminal (14) comprises the stepsof measuring objective QoS parameters (t, d, c); and correlating saidobjective parameters (t, d, c) with subjective parameters (Q)representative of the QoS as perceived by the user of said terminal(14).
 8. Method as claimed in claim 5 characterised in that a step isprovided for updating (140), by said telecommunications network (12, 18)said terminal (14) in regard to at least the function of generating theQoS information.
 9. Computer product able to be loaded directly in theinternal memory of an electronic computer and comprising portions ofsoftware code to implement, when it is executed on an electroniccomputer, the method as claimed in claim
 5. 10. Terminal (14) formeasuring the quality of service relating to services distributed by aservice apparatus (16) through a telecommunications network (12)comprising: first modules able to generate Quality of Service (QoS)information; second modules able to transmit said QoS information tosaid telecommunications network {12, 18); characterised in that saidfirst modules comprise measuring modules able to measure objective QoSparameters (t, d, c); and correlating parameters modules, able tocorrelate said objective parameters (t, d, c) with subjective parameters(Q) representative of the QoS as perceived by a user of said terminal(14).
 11. Terminal as claimed in claim 10 characterised in that saidcorrelating parameters modules comprise a correlation functiondetermined experimentally on the basis of statistical data.